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Abstract. Logic programming provides a very high-level view of programming, 
which comes at the cost of some execution efficiency. Improving performance of 
logic programs is thus one of the holy grails of Prolog system implementations 
and a wide range of approaches have historically been taken towards this goal. 
Designing computational models that both exploit the available parallelism in a 
given application and that try hard to reduce the explored search space has been 
an ongoing line of research for many years. These goals in particular have moti- 
vated the design of several computational models, one of which is the Extended 
Andorra Model (EAM). In this paper, we present a preliminary specification and 
implementation of the EAM with Implicit Control, the WAM2EAM, which supplies 
regular WAM instructions with an EAM-centered interpretation. 

1 Introduction 

Logic programming provides an abstract and high-level view of programming in which 
programs are expressed as a collection of facts and predicates that define a model of 
the problem at hand and against which questions may be asked. The most well-known 
example of this paradigm of programming is Prolog, which has been sucessfully used 
in applications of many different areas. One line of work that has been followed to 
address performance issues is parallel execution: parallelism allows logic programs to 
transparently exploit multi-processor environments while extensions like co-routining, 
constraints and tabling go a long way towards reducing the problem's inherent search 
space. Some or all of these together act as the foundation on which to build more ad- 
vanced techniques towards obtaining maximum performance. 

From the experience gained in implementing the Basic Andorra Model, D.H.D. War- 
ren made a more radical proposal, the Extended Andorra Model, or EAM [12], in which 
the conditions in which independent computations might be carried out are eagerly 
sought. In this article, we present a concrete implementation of the Extended Andorra 
Model, the WAM2EAM, which differs from other approaches taken in the past because 
we are compiling straight WAM code into C, 1 adopting an EAM computational model, 
resorting to GCC extensions. 

This paper is structured as follows: Section 2 presents a short survey on the road 
leading up to our current implementation as far as the EAM is concerned, from the 
Andorra Principle to the BEAM. Section 3 describes the EAM in more detail and lays 



1 We are targetting C with GCC extensions, such as label values and indirect jumps. 



down the theoretical groundwork of the WAM2EAM and delves more deeply into its prac- 
tical implementation from WAM code compilation to the data structures and execution 
control of the EAM-based generated C code. Finally, Section 4 uses a concrete Prolog 
example and succintly describes its compilation and execution from start to finish. 

2 State of the Art and Related Work 

A significant body of research on Logic Programming has been directed towards im- 
proving the performance of Prolog. One important line of research towards this goal 
is the exploitation of the different forms of implicit parallelism, present in Prolog pro- 
grams. Several approaches have been devised over the years but we shall focus on the 
systems which allow for the transparent parallel goal execution, in particular the "An- 
dorra" family of languages which includes Andorra-I, AKL and the BEAM. 

2.1 The Andorra Principle 

David H. D. Warren proposed the Basic Andorra Model (BAM), 2 geared towards the 
execution of logic programs, in which a goal is called determinate if it has at most one 
candidate clause. In this model, deterministic goals should be executed first, thereby 
reducing the nondeterminate "guesswork" to the minimum possible. Only then, once no 
deterministic goal remain to be executed, should a non-deterministic goal be selected 
for execution. 

A system incorporating the Andorra Principle reduces the search space of logic 
programs by having deterministic goals execute first and only once, rather than have 
them re-executed several times in different points of the search space. This behavior is 
also known as "sidetracking." Also, as a desirable consequence, deterministic goals may 
generate constraints (bindings) which may further reduce the number of alternatives in 
other (non-deterministic) goals, possibly even making them deterministic. 

Another interesting advantage is how all deterministic goals can execute in parallel, 
so long as they do not run into binding conflicts. Parallelism in the BAM comes in two 
flavours: 

- AND-Parallelism - deterministic goals run in parallel 

- OR-Parallelism - the exploration of different alternatives to a goal is done in parallel 

The BAM may also alter the semantics of programs, in that the order of the solutions 
for a given goal may be different from that resulting from sequential Prolog execution. 
This may cause otherwise nonterminating programs to reach a solution. 

There are, however, a few issues inherent to this sort of computational model: 

- Finding which goals are deterministic can sometimes be difficult as predicates with 
more than one clause may actually have a single matching clause for a given query. 

- Concurrency may break Prolog semantics, for instance by executing a pruning di- 
rective (e.g. cut) too early. 

2 Not to be confused with Van Roy's Berkeley Abstract Machine, used in the Aquarius Prolog 
system [5]. 
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The best-known implementation of the Basic Andorra Model is Andorra-I [3,2]. It 
exploits OR-parallelism and determinate dependent AND-parallelism while fully sup- 
porting Prolog, however, despite good results, the system is limited by the fact that 
co-routining and AND-parallelism can only be exploited between determinate goals. 

Shortly after, Warren went further and proposed the Extended Andorra Model 
(EAM) which improved upon the ideas of the BAM, namely by trying to explore inde- 
pendent AND-parallelism. This lead to a two major approaches: 

- AKL: The Andorra Kernel Language (AKL) [4, 6] was designed by Haridi and 
Janson and was the course followed at SICS. It concentrated on the idea that a new 
language was needed, based on the advantages of the EAM, which would subsume 
both Prolog and committed-choice languages. AKL distinguished itself by featur- 
ing an explicit control scheme, as programs were written using guarded clauses, 
where the guard was separated from the body with a sequential conjunction, cut or 
commit operator. 

- EAM with Implicit Control: In contrast to AKL, David H. D. Warren and other 
researchers at Bristol worked towards an implementation of the EAM with implicit 
control. Its main goal was to take advantage of the Andorra Principle while allevi- 
ating the burden on the programmer. 

2.2 The BEAM 

The Boxed EAM (BEAM) is an implementation of the EAM design with implicit con- 
trol, developed at University of Porto, Portugal [7-10]. The beam's initial goal was to 
prove the feasibility of Warren's design for the EAM, and as a first step it concentrated 
on the original rewriting rules of the EAM, so formally it was defined through rewrite 
rules that manipulate AND-OR trees as well as simplification and optimization rules 
used to simplify the tree and discard boxes. It also made use of a general control strat- 
egy, which is used to decide when and how to apply each rule. 
The main operations of the BEAM are: 

- Reduction expands a goal G into and or-box. 

- Promotion promotes constraints from the an inner AND-box to an outer AND-box. 

- Propagation propagates constraints from an outer AND-box to the inner-boxes. 

- Splitting distributes a conjunction across a disjunction. 

Adding to these are a few simplification and optimization rules, all of which are de- 
scribed in [9]. 

Apart from AND- and OR-boxes, there's also another kind of box contemplated 
in the BEAM which is the choice-box. These are special OR-boxes created when the 
clauses defining a procedure include a pruning operator, generically designated by °/«. 
The original EAM supports two pruning operators, cut and commit. 

The EAM tries to keep the control implicit as much as possible, contrary to AKL 
for instance. Therefore, in the BEAM, the control decisions are based exclusively on 
information implicitly extracted from the program. Moreover, one of the main goals of 
the EAM is to perform the least possible number of reductions to obtain the solutions 
to a goal. BEAM'S control strategy is geared towards this goal. 
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The BEAM also does not attempt to do all the work by itself, instead relying on the 
output of an existing Prolog compiler, in this case YAP Prolog. The BEAM was built 
as an extension to YAP. It differs from the work reported herein in that the BEAM is 
meant to be an interpreter, whereas WAM2EAM takes WAM code and compiles it to C. 

Non-termination A central problem found by the developers of the BEAM was a 
consequence of EAM's execution scheme: as long as they do not bind any (external) 
variables, the EAM allows the early parallel execution of nondeterminate goals. In the 
worst case, this may lead to non-termination for certain recursive predicates. The pro- 
posed solution was based on both eager non-determinate promotion and tabling which, 
on the one hand guarantees that the computation ends in programs that have finite solu- 
tions and on the other hand, with tabling, allows for the reuse of solutions to goals. 

3 The Extended Andorra Model and WAM2EAM 

The Extended Andorra Model (EAM) is the foundation for the work we carried out 
with WAM2EAM. The ideia is to perform as much work as possible in parallel, exploiting 
all the available forms of parallelism: 

- Or-parallelism, related to exploring the various alternatives of any given goal. 

- Indendent AND-parallelism, within a conjunction of goals that do not share any 
variables. 

- Dependent AND-parallelism, between goals that do share variables. 

The main extension of the EAM over the BAM is that non-deterministic goals are al- 
lowed to execute in parallel so long as they do not bind any external variables. 

Our purpose is to provide a concrete implementation of the EAM with implicit 
control. It departs from existing work because it compiles regular WAM code into C, 
using an EAM runtime specification. Therefore, the biggest challenge and arguably the 
most interesting aspect of this work, is going from one paradigm (Prolog compiled onto 
the WAM) to a different one (EAM) with a single tool. 

Based on a configuration AND-OR tree at all times, the way to evolve this config- 
uration is by using one of several rewrite rules on it and an execution control scheme 
to manage the application of these rules. We do not present the rewrite rules used by 
WAM2EAM, as these are closely related to those presented in [12]. 

The major challenge in WAM2EAM certainly is to go from a WAM program and re- 
interpret it from an EAM point of view. To accomplish that, we take the GNU Prolog's 
textual WAM output and proceed from there. The idea is to generate C code for an 
EAM runtime. This entails doing things quite differently from previous work such as 
WAMCC [1] or B-Prolog [11]. WAM2EAM has two major aspects to it: 

1. the compiler, comprising the parser and the C code generator, 

2. the runtime, a collection of data structures, logic and execution control that imple- 
ments the EAM execution model. 

The remainder of this section discusses design and implementation of the compiler 
and runtime. We work a running example based on the sample Prolog code shown in 
figure 1. 
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mam 



p(X). 



p(X) 



q(X), r(X). 



q(l) 
r(2) 



q(2). 
r(3). 



Fig. 1. Sample program 



3.1 Parsing WAM instructions 

We used GNU Prolog because its compilation passes are fairly simple and it is easy 
to materialize the WAM representation of Prolog programs. The following is a snippet 
of code which is the GNU Prolog WAM representation of the p/1 predicate from the 
earlier example. 

predicate (p/1 , 5 , static .private , user , [ 
allocated) , 
get_variable (y (0) ,0) , 
put_value(y(0) ,0) , 
call(q/l), 
put_value(y(0) ,0) , 
deallocate , 
execute(r/l)] ) . 

We built a parser for this representation in Bison, which constructs an abstract parse 
tree of the WAM program. 

3.2 C Code Generation 

An interesting aspect of WAM2EAM is how we take a sequence of instructions intended for 
the regular WAM and directly re-interpret them in an EAM context, yielding appropriate 
patterns of target code. Be that as it may, a lot of the WAM instruction set translates as- 
is to the EAM representation. Simpler instructions, such as put_value for instance, are 
supposed to do exactly the same thing in the WAM and in the EAM and the same goes 
for indexing instructions like switch.*. In a few cases, such as proceed, WAM2EAM 
simply disregards the instruction as not being useful in the EAM setting. 

At closer inspection of the WAM instruction set, the major difference in paradigm 
impacting the C code generation concerns the instructions dealing with non-determinism 
Whereas the WAM deals with choice points, creating and destroying them as needed, 
the EAM, by doing away with the WAM's stack-based representation and using an 
AND-OR tree based configuration instead, deals with OR-boxes when it comes to set- 
ting up and exploring alternatives. 

Once every detail of the original program has a C representation - an abstract parse 
tree - the idea is to walk through it and emit a bit of C for each predicate and for 
every WAM instruction inside it. For each internalized predicate, a block of C code is 
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generated, setting up a new AND-box which contains a suitable number of allocated 
local variables, 3 binding those variables to its parent OR-box corresponding predicate 
arguments and defining each of those variables' home as the very AND-box that is being 
created. The output code is generated by this code in the compiler: 

emit(8, "a = new_and_box (o, °/,d, ab_id++) ; \n" , max_var_idx+l) ; 
for (i = 0; i < n; i++) 

emit (8, "bind (a->locals [%d] , o->args [%d] ) ; \n" , i, i) ; 
for (i = 0; i < max_var_idx+l ; i++) 

emit(8, "ASREF(a->locals [7„d] )->home = a;\n", i) ; 

max_var_idx reflects the maximum number of variables used in this predicate, account- 
ing for possible temporaries in all of its clauses, potentially a single one if deterministic. 
Looking now at the C code for a clause with two local variables, it might look something 
like this: 

a = new_and_box (o, 2); 

bind (a->locals [0] , o->args [0] ) ; 

bind (a->locals [1] , o->args[l]); 

This allocates a new AND-box with two local variables, as a child of the current OR-box 
(whose address is kept in o) and both of those variables are then immediately bound to 
whatever are the first two parent OR-box arguments. This creates variable chains across 
the AND-OR tree, reflecting the same concept found in Prolog clauses where a newer 
variable might refer to an older one. 

A second pass through the WAM instructions for the clause is needed to generate 
code for each actual WAM instruction by traversing the list built by the parser. 

while (instrs) { 

print_instr (instrs->head, (*a)->name, n, max_var_idx+l , FALSE) 
instrs = instrs->tail; 

} 

print_instr then goes through a large switch instruction that finds the appropriate 
bit of C code to emit for each WAM instruction, having the EAM execution scheme in 
mind. WAM instructions, which by now we regard as EAM instructions in their own 
right, are roughly divided in three major groups: 

Choice point manipulation These are the try*, retry* and trust* instructions. 
We no longer think in terms of choice point frames, instead looking at managing non- 
determinism by way of OR-boxes. A predicate with only one clause consists of an 
OR-box with a single alternative (and thus a single descendant AND-box) whereas a 
non-deterministic predicate (ie. having more than one clause) is translated as an OR- 
box with as many children AND-boxes as there are possible clauses. A more in-depth 

3 The exact number is determined by inspection of the WAM code in the body. 
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description of how OR-boxes actually deal with alternatives will be given after we in- 
troduce the major data structures used throughout WAM2EAM. In practice, an instruction 
like try_me_else (L) (or retry _me_else (L), for that matter) for predicate q(l) 
simply defines the next alternative in the current OR-box, generating the following bit 
of C code: 

o->alt = &&P_q_l_C4; 

Execution Control The call and execute instructions are responsible for predicate 
calling, in effect jumping to the appropriate place in the code where to start executing 
the called predicate. They also need to setup a return address for when this predicate 
is done executing. This is accomplished by emiting a C label and configuring the cur- 
rent AND-box continuation to that label, using GCC's label address extension. With 
this, once the called predicate is done, it will proceed to whatever AND-continuation 
is available in its AND-box, in effect returning here and resuming execution. The dif- 
ference between call and execute is precisely what to do after the called predicate 
is done with. Whereas in the former case, it simply continues executing whatever is 
left in the current predicate, the latter means this was the last goal in the current clause 
and it should look for a continuation above, in the Prolog execution chain. Here's how 
the call instruction is translated to C: For example, the pattern of code generated for 
calling the goal q(X) in our example is: 



/* call(q/l) */ 






q_enqueue (a->and_conts ,&&R1) ; 


// 


setup AND-continuation 


o = new_or_box(a, 1) ; 


// 


create new OR-box 


o- >args[0] = a->locals [0] ; 


// 


preload A registers on the new OR-box 


goto P_q_l; 


// 


jump to the predicate's code 


Rl: 


// 


return label 



/* further code.. */ 



Variable manipulation and unification This type of instructions is also handled quite 
differently within the EAM. Simple instructions such as put .value or get.variable 
are basically the same, but unification needs to be looked at more carefully, as trying 
to bind variables which are not local to the current AND-box leads to suspension of 
execution and triggers a search for work, elsewhere in the code. AND-box suspension 
and the WAM2EAM execution scheme will be looked upon in a bit more detail shortly. 

3.3 Generated code structure 

Since we're generating a valid C program, ready to be compiled by GCC, there's a 
question of what layout this code will use. One important constraint is that we must 
be able to jump back and forth between different predicates, in order to implement 
predicate calling and returning. Also, we need to jump to random places in the code 



7 



when attempting to resume a suspension. Considering that it is illegal to use C's goto 
between different functions, 4 generating one C function per predicate is not an option, 
no matter how tidy and comfortable that would be from a structure point of view. 

One possible alternative then is to implement the entire program as a single function 
and delimiting predicates using unique labels. This way, jumping from one point in the 
code to another remains within the bounds of the one function and correct indentation 
when emitting the code will hopefully not make it a burden to look at. We also must 
be careful when jumping to a point of code from out of nowhere, since the correct 
environment must be replaced, namely the current AND- and OR-boxes. Other than 
that, all it takes for jumping around the code is the address to jump to and making good 
use of GCC's labels as values extension. 

int program () 
{ 

/* ... */ 
P_p_l: { 

a = new_and_box(o, 1) ; 

/* ... */ 

o = new_or_box(a, 1) ; 
goto P_q_l; 

/* ... */ 
P_q_l: { 

a = new_and_box(o,l) ; 

/* ... */ 

} 

3.4 Runtime Data Structures 

The runtime half of WAM2EAM is itself broken into two major steps and these are where 
we significantly depart from the WAM way of doing things and completely focus on 
EAM. First, executing the C code previously generated by the compiler will incre- 
mentally build the configuration, an AND-OR tree that gets constructed, modified and 
pruned as execution of the code proceeds. The way for this to happen is by applying in 
turn the different AND-OR tree rewrite rules. 

The most important data structure in WAM2EAM is the AND-OR tree, also known as 
the configuration. An AND-OR tree is so called because it is composed of two kinds of 
nodes: the AND nodes, corresponding to Prolog clauses and the OR nodes, consisting of 
Prolog goals. We'll shortly get into more detail on how both these nodes are structured 
and how they interact with each other. For now, it's important to note that no two nodes, 
or boxes, of the same type are directly connected in an AND-OR tree, so any path from 
the root to any leaf is always made of alternate types of boxes. A parent OR-box has 
AND-box children, each of which has descendent OR-boxes, and so on. Moreover, the 
root is always an OR-box. 

4 We may not reenter an existing C stack frame. 
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AND-boxes They represent clauses, so there is one AND-box in the configuration for 
every clause in the Prolog source code. So, for instance, a non-deterministic predicate 
having four different clauses, would consist of four AND-boxes, one for each clause. 
AND-boxes are a lengthy structure in WAM2EAM in that they play a critical role. They are 
home to the clause's local variables, they need to keep track of their continuations (e.g. 
where to find the code for the next goal in the clause once the current goal is done with) 
and they also may or may not be suspended at any point in time. Finally, promotion also 
impacts AND-boxes directly, so they also have mechanisms to deal adequately with 
that. And, of course, they spawn (and in turn descend from) OR-boxes corresponding 
to the reduction of their body goals. 

OR-boxes These represent goals and are created everytime a new goal is executed. 
Their primary concern is dealing with non-determinism by managing goal alternatives, 
namely holding an address for the next alternative for the current goal at all times. They 
also carry the goal's arguments when the goal gets called in order to pass them initially 
to each clause's AND-box as initial values. OR-boxes thus spawn an AND-box for each 
clause they invocate. 

3.5 Suspensions 

As we have seen before, caution must be taken when an attempt to bind a variable 
is made. Only in case the variable is local to the current AND-box will binding be 
allowed to occur. Otherwise, the AND-box is said to be suspended on the offending 
variable and execution proceeds elsewhere, namely to the next alternative in the current 
OR-box. Execution can only return to this AND-box when certain conditions are met, 
namely when the variable becomes local to the current AND-box or it gets bound from 
elsewhere. In the latter case, when the suspension is resumed, the attempted binding 
that triggered the suspension in the first place is retried and it either checks OK or it 
fails against the prevailing (earlier) binding. 

In order to correctly deal with these situations, we need to wrap instructions wherein 
a suspension might occur with some code that actually checks for "offending" binding 
attempts, namely trying to bind a non-local variable. We do this by having every unifi- 
cation instruction check whether the dereferenced variable is already bound and if not, 
whether it is local or external to the current AND-box. The result of this verification 
is then returned as a meanigful code to a wrapping CHECK ( ) macro, which then acts 
accordingly. Faced with a unification attempt, the outcome can then be any one of: 

BIND_SUSP the variable is not bound yet and it's not local to the current AND-box 

either. The current AND-box suspends on this variable. 
BIND.OK the variable is not bound and it's local, so the binding succeeds. 
CHECK OK the variable is bound and its value is the same as the one being attempted 

in the binding, so execution may proceed. 
CHECK JAIL the variable is bound and its value differs with the one being tried. The 

configuration branch rooted in the current AND-box fails and is pruned off the tree. 
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Because of suspensions, for every non-trivial program it's easy to see that we quickly 
arrive at what we call a stuck configuration, an AND-OR tree where all leaf AND-boxes 
are suspended. As we don't stop execution anytime a box suspends, it is only when no 
more code is left to execute that we have a problem. At this time we try to apply one of 
the rewriting rules, in particular giving priority to determinate rules such as determinate 
promotion. By promoting an inner AND-box into an outer AND-box, the variables 
inside it are also promoted which means they become closer to the AND-box where 
they will actually be local, eventually allowing for bindings to happen or suspensions 
to resume. 

3.6 Deterministic Promotion 

As explained in the previous section, actions (or rules) that contract the configuration 
are desirable. On the other hand, expanding goals also expands the configuration, as 
AND-boxes give way to OR-boxes which in turn give way to more AND-boxes and 
so forth. Deterministic promotion, being the only rule that eliminates boxes, is highly 
sought after. This rule is only applicable to OR-boxes with a single alternative. 

Implementation-wise, promoting an AND-box context (variables, suspensions and 
continuations) into another requires maintaining their environments coherent. In other 
words, if the resulting AND-box contains the union of both sets of locals variables 
from the two AND-boxes involved in the suspension, then what was the first variable 
in the inner (promoted) AND-box is probably no longer the first variable in the outer 
(resulting) AND-box after promotion. This lends itself to all kinds of mayhem when 
code still refers a->locals [0] (WAM register X(0)) when the actual variable is now 
at a->locals [1] . 

To cope with this problem, we opted to introduce the concept of AND-box group- 
ings. Each AND node in the configuration is actually a group of one or more complete 
AND-boxes, forward-connected among themselves by a pointer which indicates the 
next box in the group. Moreover, every box in the group is also linked to the first - the 
head. This situation is illustrated in figure 2. 

This way, each box environment remains pristine, as originally constructed, and it's 
safe to resume from a suspension point as far as accessing local variables is concerned. 
It's important to note that a variable is local to the current AND-box if, after derefer- 
encing, its home AND-box is in the same group, i.e. has the same head. 

3.7 OR-split and non-deterministic promotion 

Desirable as deterministic promotion might be, its occurence is heavily constrained as 
we have shown in the previous section. The OR-box must have a single alternative and 
for predicates with multiple clauses that's frequently not the case. It is quite common 
for a configuration to get stuck with no chance for deterministic promotions to occur. 
When it comes to this, there is no other choice than to perform what we call an OR-split 
which forces a situation where a determinate promotion may happen. 

Simply put, we elect an OR-box with more than one alternative to act as the root 
of a subtree to be cloned. In the original subtree, only one alternative remains, while in 
the cloned subtree, every other alternative is present. This way, all alternatives remain 
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Fig. 2. On the left: an AND-box grouping made of 3 different AND-boxes. 



in the overall configuration, ensuring correctness of the program, yet an opportunity 
for deterministic promotion now exists. Note that if the selected OR-box contains only 
two alternatives, we arrive at the special case where the OR-split induces two different 
deterministic promotion possibilities: one in the original box and another in the cloned 
box. 

The choice of OR-box to split may be guided by heuristics, yet at this early stage 
we're simply going with the leftmost OR-box suitable for splitting. Also, from the cho- 
sen box's alternatives, we're picking the leftmost one to remain in the original branch 
and all others to be moved to the cloned subtree. Actual cloning is only needed for the 
parent AND-box and any siblings of the chosen OR-box. OR-split is the least desirable 
rule, because with cloning entire branches of the tree, it quickly becomes expensive. 



3.8 The scheduler 

The need to decide which rule to apply led to the implementation of a scheduler. This 
scheduler is called the first time after all alternatives and continuations are exhausted 
and no answers were produced. In other words, when the tree is stuck we ask the sched- 
uler for guidance. 

The implementation of the scheduler is part of the runtime code and is implemented 
as a C macro. It basically follows a hierarchy of possible events and acts accordingly for 
each outcome. First of all, in the event that a variable that had suspensions got bound, it 
tries to resume from any suspension pending on that variable. If none are found, it looks 
for an alternative in the current OR-box. If found, it continues execution from there, oth- 
erwise it tests the tree to see if it's stuck. If it is, it tries to apply deterministic promotion 
in order to try to move on or, if that fails, it resorts to applying non-deterministic pro- 
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motion, by way of an OR-split. Putting this as the last choice makes sense, because it is 
also the most expensive operation. 

It's interesting to note the reason why the scheduler is implemented as a macro 
instead of a function, despite being a little involved and lengthy, it is because it may 
involve jumping to any point in the code, be it a suspension point, a continuation or 
an OR-alternative. Again, we are faced with the problem of not being able to jump 
between different C functions, so its being a macro is sufficient. The control flow for 
the scheduler is depicted in figure 3. 



Start 



QR-alt available 




Fig. 3. The scheduler's flow diagram. 



4 Example Execution 

Getting back to our previous Prolog example of figure 1 , we now give an overview of 
how WAM2EAM goes from WAM code to EAM execution. 
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As previously mentioned, WAM2EAM-produced C code, when executed, comprises 
two diferent phases. The first one is made of consecutive reduction steps, expanding 
the AND-OR configuration as execution continues through the code. For each called 
predicate, a new OR-box is allocated, spawning a child AND-box for each of the predi- 
cate's clauses. Only trivial examples won't lead to suspension, as variable chaining be- 
tween different predicates immediately induces external variables on some AND-boxes. 
This means that, at first, almost any binding attempt will lead to AND-box suspension, 
forcing execution to look elsewhere in the code, namely in the current OR-box's next 
alternative. So, in our example, it's easy to see how variable X is only local to the AND- 
box corresponding to the only clause for the main predicate and thus every fact for q 
and r will lead to suspension over X. After all clauses are executed, we get to a stuck 
configuration as seen on figure 4. 



1 

addr; 0x100140 
#locals: 1 
susp - !: 



^locals: 1 
susp"?: 




Fig. 4. Stuck configuration. 



From now on, the configuration is modified by repeated application of rewriting 
rules, managed by the WAM2EAM scheduler. In this case, as no OR-box contains a single 
(suspended AND-box) alternative, no deterministic promotion is possible, so we need 
to resort to applying the OR-split rule on the leftmost OR-box, parent to suspended 
AND-boxes. 

Because there were only two alternatives to the split OR-box, it means one stays in 
the original branch while the other is moved to to the cloned branch and two determin- 
stic promotions spots now exist (Figure 5). Were there more alternatives and only one 
deterministic promotion opportunity (in the original branch), the cloned branch would 
hold two or more alternatives, and thus not be ready for deterministic promotion. So we 
apply deterministic promotion to the leftmost AND-box, resulting in the configuration 
shown in figure 6. 
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addr 0x10014(1 
floods: I 
mupl! 



adcriOilin'Viiii 
locals: I 
susp?: I 



addr: 0x100220 




addr: 0x]004fD 
fflocali.: I 
imp?' I 



addr0il00570 
iflocals: 1 
susp?: 1 



addr: 0*100530 
fflncals: 1 
SUSp?: 



addr: 0xl003d0 
flocak: I 
imp?' I 







addr OxlOOM) 




addr 0x100720 


((locals: 1 




tftacals: 1 


susp?: 1 




susp?: 1 



Fig. 5. After OR-split. 




addr: 0x100220 


addr: 0x100300 


#lneah: 1 


-I.--- 1 


SUSp?: 


SURp?: 1 



fflncals: 1 



susp?: I 



i-r: Us HO? :i) 



susp?: I 






f 


addr: 0x1003d0 


floods: l 


susp 


»: 1 







addr: OxIOOfidO 




addr: 0x100730 


florals: 1 




flocals: 1 


susp?: 1 




susp?: 1 



Fig. 6. After deterministic promotion. 
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After promotion, we attempt to restart the promoted and previously suspended box, 
but it immediately suspends again as its local variable, when dereferenced, still belongs 
to an another AND-box - the main AND-box in this example. Applying promotion to 
the analogous case in the cloned branch leads to exactly the same outcome, so we're 
again at a stuck configuration scenario. From here on, it's easy to see that repeated appli- 
cation of the WAM2EAM rules will result in a sequence of OR-split, promotion, suspension 
until an AND-box suspension is restarted and the variable in it that caused suspension 
is finally local to the current AND-box group. When that happens, the binding succeeds 
(or fails) and every AND-box suspended on this variable is "awakened". Then, there 
are two possible outcomes: 

- CHECK_OK - the attempted binding at the suspension point unifies with the one 
already in place. This generates an answer to the program query and in our example 
that answer is X=2. 

- CHECK_FAIL - the attempted binding fails to unify and that means this entire 
branch rooted on the current AND-box group, simply fails and is pruned from the 
configuration. Execution then looks to the scheduler for where to proceed. 

As the EAM (and in turn WAM2EAM) does not contemplate explicit backtracking, the 
way to generate other answers for any given program, is to continue exploring different 
branches of the configuration looking for other successful bindings. In this case, none 
could be found as the other branch would also have a conflicting binding, leading to its 
pruning off the tree. 



5 Concluding Remarks & Future Work 

We are convinced that our goal of generating a program following EAM semantics from 
a classical WAM one has been met, even if with some restrictions for the time being. 
Performance is not yet an issue but will become one as we develop further aspects of 
this implementation. It is interesting to see that it is feasible to have an EAM execution 
model without the Prolog compiler being aware of the fact. 

Further work is to focus on the introduction of pruning operators - in the case of 
cut this is straightforward to recognize from the WAM code but for commit special 
measures will have to be taken as it is not inherently accounted for by the Prolog-to- 
WAM compiler of GNU Prolog. 

One of the driving motivations for generating AND-OR trees and having them ma- 
nipulated as per the EAM was to bridge this computational model to one with tabling, 
as found in XSB or YAP Prolog. Although we haven't begun to do so, this goal remains 
valid. 

There are not many EAM implementations; we need to experimentally assess our 
work comparing it to the BEAM and other Prolog implementations in terms of perfor- 
mance, particularly when we work towards a parallel version of WAM2EAM. 
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